KERI white paper

インターネット上の異なるデバイスやネットワーク間で、信頼できる接続や通信のための基盤となる概念です。この層は、インターネットの基本設計には含まれていないセキュリティ機能を提供するために追加されるもので、異なるシステムやプロトコル間での信頼性を確保するための仕組みを提供します。元々インターネットプロトコルにはセキュリティが組み込まれておらず、これを補うために後から「スパニングレイヤー」という形でセキュリティ機能が追加されることがあります。

Binding

Identity sistem security overlayの重要な本質的特徴は, 「Controller, identifier, keypaierを結びつける」ことである

https://scrapbox.io/files/670cbe5fa64fe9001cb83cc1.png

アイデンティティシステムの管理者の機能は, 排他的に他のエンティティによる識別子の使用を許可すること

エンティティと識別子の間のバインディング

許可されたエンティティをコントローラー(User)

これにより, IPアドレスなどのリソースへのマッピングができる

暗号化キーペアの公開鍵をこのエンティティと識別子にバインディング

署名することで識別の使用が許可されていることを証明できる

識別子が管理者から供給される場合, 管理者の継続的な許可(使用料の支払い)を条件としている -> コントローラー, 識別子, キーペアの結び付きの安全性は, 管理者の信頼や維持, 管理するためのコンピューティングインフラストラクチャの信頼できる安全な運用に依存している

つまり, コントローラーはIDを借用しているに過ぎない

ex: CA, DNS

主な弱点は, 「証明書を介したキーペアと識別子の結合の確立が, 本質的にそのインフラの誤った運用管理に対して脆弱な, 不可欠なコンピューティングインフラストラクチャに依存していること」

Trust Basis と Trust Domain

root-of-trust: コンポーネントやプロセスが依存するシステムのコンポーネントまたはプロセスのことを指す

「信頼性の高いセキュリティ特性を備え, システム内の他のコンポーネントやプロセスが依存できる信頼の基盤を提供する」

TEEとかの話に繋がる？？Yudai.icon

複数のroot-of-trustが存在する場合があり, 以下のように定義する

Primary root-of-trustは代替不可能である

不可欠なコンポーネントである

Secondary root-of-trustは代替可能である

冗長的に提供される可能性もある信頼を提供する

Trust basisの定義:

Controller, identifier, keypairを結びつける

つまりdidでいうdid documentYudai.icon

Trust domainの定義

Trust basisに依存する相互関係の生態系である

大多数のIDベースのセキュリティメカニズムにおける主な問題の1つは, コントローラ, 識別子, キーペア間のバインディングが, 管理上の権限付与と関連するTrust baseへのロックの両方を受け入れている場合に生じる

トラストベース間で自己管理及びポータビリティが可能な安全な相互運用可能なバインディングシステムの設計を可能にする

めっちゃDIDの相互運用可能性についてだと思うんだけど, これを識別子として考えるのが問題であって, 暗号プロトコル側から解決できるってこと？？

Decentralization

「管理に関するものであり, 空間的な分散とは異なる」

Decentralization: 管理

Destributed: 場所

価値の集中かシステムは価値と権力を集中させるため, 悪意のある管理者がその集中した権力を利用して参加者から価値を搾取する誘惑を強く引き起こすことになる

-> 分散型Identity system

様々なエンティティが相互運用可能な方法で識別子の一部を管理する

言いたいことは, 管理者の分散化は必須であるってことっぽいYudai.icon

ブロックチェーンってものが1つ重要だと思われる理由はこれ

Type of Self-Certifying identifiers

基本:

Public digital signing keyのBase-64エンコードの前に付加されたBase-64派生コードで構成されるprefixが含まれる.

https://scrapbox.io/files/670ccfc75c97f7001cd8ca99.png

公開鍵情報を識別子に組み込むって大切なんやねYudai.icon

これによって,実はdid:keyと同じで, pkからdidを導き出せるためVDRが必要なくなる？？

ただどこでこの生成を行う？

ローカル？

Identity system security overlay

root-of-trust

生成プロセスにおいて, 1つまたは複数の署名キーペアと識別子プレフィックスとの間に一意の結合を行うという点で暗号学的である

sources-of -truth

権限のあるステートメントを作成できる人物またはothers.

ルート認証は自己認識識別子を完全に排他的に制御する

loci-of-control

心理学用語で, その人が統制可能だと感じている生活の範囲を指す

「誰が何を制御するか」

ステートメント:

識別子の作成, 発行の管理

識別子に対する操作の管理

制御の移転

識別子の制御を異なるキーペア, マルチシグなどの異なる署名スキームに移転することができる

識別子の委任

独自のキーセットを持つ新しい識別子が作成され, ある程度の管理権限が承認される

https://scrapbox.io/files/670cde11b9ef7f001dd45683.png

Autonomic Identifier(AID)

Autonomic identifier: 自己管理または自己統治機能を持つものを指す

自己管理機能は自己認証である

発行時に識別子を制御するキーペアに一位に結びつけるprefixが含まれる

Autonomic Namespace

Name space: 関連するオブジェクトの集合に対するシンボルまたは識別子のグループ化である

自己証明プレフィックスを持つ名前空間として定義する

自己認証プレフィックスは, その名前空間に対する流fixと管理権限の暗号学的検証を提供する

Autnomic namespaceの各識別子は, その識別子をprefixとして含み, prefixは公開鍵や開始するキーペアの公開鍵から一意に導入される識別子である

識別子に対する管理権限を証明するためのチャレンジへの応答が含まれる

このチャレンジへの応答のための権限の認証についてもっと知りたいYudai.icon

Trust spanning layer

「インターネット上の全てのやり取りに対して単一の信頼領域をもたらす, 普遍的な信頼基盤」 -> しかしこれ難しいため, Spannning layer

サポートアプリケーションが相互運用できる単一のインターフェースを提供すること

セキュリティの観点では信頼できるスパンは, 単一の相互運用可能なメカニズム, プロトコルを提供し, 全てのスパンされた信頼ドメインが,信頼ベースによってサポートさDPがている

https://scrapbox.io/files/670cec4fe99921001ca15787.png

「KERIステートメントの標準セットを使用して相互運用する信頼ベースまたはプラットフォーム」

Key management

鍵管理の主なタスクは, Reproducution, Recovery, Rotation

Reproducution

鍵のペアの作成と派生, 秘密鍵の関連付けと保管が含まれる.

HD鍵を使っておけよって書いてあるwYudai.icon

Recovery

紛失した際にどう復元を行うか

Rotation

安全にルート権限のキーペアを効果的に移行することである

Rotation history

検証者はそのidの鍵のローテーション履歴を知っている必要がある

1番初めに生成するキーペアはルート権限を行使する手段であり, この鍵を移転することができる

危殆化後のrotation

長期間にわたる露出に起因する危殆化のリスクを限定する

すでに悪用が発生している場合のローテーション

コンポーネント

One-way function

一方向の計算は容易だが, 逆方向への変換や逆方向の計算は実用的ではない

Large integer Encoding

標準: RFC-4648のBase64 URL Safe encording

大規模な整数, 派生するpfefix, 公開鍵, 署名, ダイジェスト, およびそのほかの要素をエンコードするために使用される

Qualified Cryptographic Material

識別子, 公開鍵, ダイジェスト, 署名など素材の派生プロセスの仕様を素材に付加する素材の表現である

Qualified Cryptographic Materialのコンテキストおよび位置によって使用される派生コードの種類と派生コードの解釈方法の両方が決定される

重要な位置:

キーイベント内

キーイベントに添付された署名

Qualified identifier

一意に導出された識別子素材にその導出プロセス情報を付加した識別子の素材

prefixはこのプロトコルにおいて修飾された自己証明識別子を示すために使用される

Qualified public key

公開鍵にその派生プロセス情報を付加した公開鍵の表現である

Qualified digest

暗号強度の一方向ハッシュ処理から出力されたダイジェストの表現であり, そのダイジェストに派生プロセス情報が添付されている

Qualified signature

添付されたデジタル署名の表現であり, 派生プロセス情報が添付されている

署名スキームを含める必要がある

Hidden qualified cryptographic material item

派生には素材の暗号強度ダイジェストを生成する追加の一方向ハッシュ化ステップが含まれる

Hidden public key

派生過程に公開鍵のダイジェストを生成する追加のone-way hash処理が含まれる修飾された公開鍵のことである.

ダイジェストのみが記載されるため隠されることになる

Hidden signing threshold and public key set

署名閾値を指定し, 修飾された公開鍵のセットを続けるもので, 導出にはシリアル化された閾値指定子と修飾された公開鍵のセットのダイジェストを生成する追加のone-way hash処理が含まれる

Seal

派生コードで使用されたハッシュ関数のタイプが指定されているものの, 関連データに関するそのほかの情報は含まれていない修飾ダイジェストのこと

Self-certifying identifier Prefix

Prefix, 識別子, または複数の暗号化デジタル署名, キーペアを含む, 1つまたは複数の一方向関数によって普遍的に一意に導出される素材を含む修飾された暗号化素材の一種

Derivation: 生の公開鍵の要素や派生の他の部分を含むマッピングや順序付きタプルなどのデータ構造として表現できる

識別子prefixは識別子の名前空間を作成するために使用される自己証明識別子の一種である.

Key-pair Label

識別子prefixの省略形として, 表現内の各エンティティはA, B, Cなどのエイリアスとして大文字のアルファベット記号でラベル付けができる

エンティティAに関連する公開鍵A, 秘密鍵a

自己証明識別子には発行時に少なくとも1つの初期制御キーペアを関連づける必要がある

鍵ペアの管理

index番号を使って鍵ペアを区別する

A0とa0はエンティティAに紐づく最初の鍵ペアを表し, A1とa1のようにインデックスを振る

鍵ペアの履歴: A0, A1, A2....のように公開鍵のリストを記述できる

イベントに応じたラベリング

Rotation Key: ローテーションイベントで使用される鍵ペアをR, controllerCがローテーションで使う鍵ペアはCR

Interaction Key: 相互作用イベントで使われる鍵ペアはX.controller Cが相互作用で使い鍵ペアはCX

Transferble identifier

ローテーションイベントを通じて, 現在の制御キーのセットから新しいセットへの制御権限の移転を許可する

Controller

識別子の管理主体である.任意の時点で少なくとも1つの管理主体を持つが, 複数の管理主体を持つ場合もある.

Controller: controlling entitiesの集合全体または集合のメンバーを指す

複数の管理エンティティが存在する場合, L個の署名、各エンティティから1つずつの署名によって管理が確立される = Multi-signature

Statement

電子署名が可能なあらゆるデータ

識別子、識別子に関連する属性やその他のデータに対して1つまたは複数の操作を実行するために使用される

Message

1つ以上の署名を添付したシリアライズされたデータ構造

Key Event Sequence Number and Event labeling

Key Event Sequence Number(SN): 各イベントに割り当てられる一意の番号で, 順序や識別に使われる.

順序の維持

精度と拡張性

符号化と保存

ラベリング

シーケンス番号はtkのように表され, kはシーケンスのインデックス

最初のイベント: t0

次のイベントはt1,次はt2

数式で表すと, t0 = 0, t1 = 1...tn = n

イベント自体にもラベル付けを行う。$ εを使う

$ ε 0のように表し, $ ε1のように表す

メッセージの表現

各イベントメッセージは署名を含むデータ構造である

$ εA = t, A, A0, A1, σA

t: シーケンス番号

A0, A1は公開鍵

σAはイベントに対する署名

Seal

イベントシーケンス内の特定の場所にデータを固定し, そのデータが正当であることを証明するための暗号学的コミットメント. データのハッシュ値やMerkle treeeの形で表されイベントシーケンスの特定のイベントに固定される

目的: シーケンス内のイベントが正当な鍵ペアによって管理されていることを証明し, データの真正性を提供する

種類:

Digest seal

外部データのダイジェストを含む最小限のseal.

外部データのダイジェストをイベントに固定し, データが変更されていないことを証明する

Root Seal

merkle treeeのルートを含むseal.

データの整合性を保証し, ハッシュツリー全体が正当であることを証明する

Event seal

特定のイベントに関連する識別子, シーケンス番号, ダイジェストを含むSeal. イベントログ内の特定のイベントを他のイベントに固定し, 正当であることを確認できる

イベンントの間に暗号学的なリンクを作り, イベントから他のイベントへのコミットメントを提供する

Location Seal

イベントの位置情報を含む.

複数のイベントが互いにクロスアンカーする場合や外部データをイベントログに固定する場合に使用される